8. 模糊测试理论追踪

手动方式有问题吗？

• 手动代码审计。
• 需要很多时间。非常慢。
• 不可能覆盖所有代码路径。
• 庞大的代码库，不可能由一个人来完成审计。
• 不太有成效。
• 事情可能会被遗漏。
• 不能涵盖所有情况。

自动化的

• 自动查找错误。非常快。
• 可以覆盖大部分的代码路径。
• 不需要担心代码的大小问题。
• 可以由个人来完成。
• 可以进一步自动化，以通知崩溃、问题。

模糊测试

Fuzzing是自动查找错误的过程。摸索器将生成或提供精心设计的程序输入，并监测其行为。如果其崩溃，则可保存测试案例以进一步分析和复现。

有各种类型的模糊测试程序，如：

1. 傻瓜式模糊测试程序

生成随机输入。

• Fuzzer - 不知道程序路径/输入文件的格式。
• User - 不需要了解文件格式/网络协议。
• 可能需要很多时间（取决于你的运气）。
• 随机输入
• 无论用户知道多少，模糊测试程序都会生成随机输入。

例如： radamsa

https://github.com/hardik05/Damn_Vulnerable_C_Program

你需要很幸运才能用这些模糊测试程序找到复杂程序中的错误。

2. 突变/生成型模糊测试程序

基于预定义的模板生成输入。

• Fuzzer - 不知道程序路径，但可以根据给定的模板生成输入文件。
• User - 需要对输入文件或协议有所了解。
• As good as a user knows about the things and can create templates.

例子: Peach, Sulley.

你可以找到错误，但需要在理解和生成文件模板或网络协议结构方面做工作。

3. 覆盖引导型模糊测试程序

使用编译时或运行时检测程序的执行情况，并能根据所走的路径生成新的输入文件。

• Fuzzer - 意识到正在进行的程序路径，并能在此基础上改变输入。
• User - 不需要知道程序路径或文件格式。
• 用户不需要做任何事情，模糊器可以根据覆盖率数据处理输入的生成。
• 突变文件并检查新的代码路径覆盖/崩溃
• 新的代码路径 -> 添加到队列中
• 崩溃 -> 保存输入值 ☺ 

例子： AFL,Honggfuzz,libfuzzer

非常有用，而且成功地找到了错误。

有趣的案例研究

无中生有的jpeg图片: https://lcamtuf.blogspot.com/2014/11/pulling-jpegs-out-of-thin-air.html

$ mkdir in_dir
$ echo 'hello' >in_dir/hello
$ ./afl-fuzz -i in_dir -o out_dir ./jpeg-9a/djpeg

基本区块、检测和代码覆盖

1. 基本模块

• 连续的代码行，没有分支。(在程序必须选择路径之前/采取新的路径之后的代码)。
• 切入点--控制来到了这个基本块。
• 出口点--控制权转到另一个基本块。

请考虑以下代码：

它在IDA中的样子：

2. 代码覆盖

• 衡量一个输入所覆盖的代码。
• 更多的代码覆盖率意味着发现bug的几率更高。

3. 检测

如何在运行时跟踪程序的执行情况，以检查正在采取哪些代码路径？

• 基本方法 - 在代码中添加printf并进行调试。（对模糊测试没有用）

• 没有提供太多的数据
• 需要做手工作业。

如果有源代码的话。

• 编译时检测- 在编译时添加检测代码。(当源代码可获得时，由afl/honggfuzz/libfuzzer使用)

• 可以自动进行覆盖测量等工作，免除了人工工作。

如果源代码不可用。

• 运行时检测 - 当源代码不可用时使用。

• 在运行时添加检测代码 (主要用于窗口、Dynamorio/Pin工具等。)

什么是AFL？

• American Fuzzy Lop
• 创作人 Michael Zelwaski
• 带有检测引导的遗传算法的模糊测试程序。
• 附有一套实用程序: afl-fuzz, afl-cmin, afl-tmin, afl-showmap etc..
• Fork 服务/持久化模式.

• Mutate the files based on various strategies. Bitflip, byteflip, havoc, splice etc.

那么，AFL是如何工作的？

• 向基本块中添加编译时检测
• Tracks block hits based on the instrumented code at block level.
• 提供编译器封包器afl-gcc,afl-g++, afl-clang, afl-clang++, afl-clang-fast, afl-clang-fast++ etc
• uses binary rewriting technique.
• 在每个基本块上添加检测
• Each basic block will have a unique random id.
• 通过相当于以下伪代码的汇编完成：
  

  cur_location = <COMPILE_TIME_RANDOM >;
  shared_mem[cur_location ^ prev_location ]++;
  prev_location = cur_location >> 1;
  A → B →C → D → E vs  A → B → D → C → E

  

Fork 服务与持久化模式

Fork 服务模式

• 在main()处停止。
• 使用fork来创建程序的克隆。
• 处理输入并创建另一个克隆。
• 节省初始化程序的时间，从而提高速度。

持久性模式

• Fork的成本仍然很高。
• 其实不需要在每次运行后都杀掉子进程。
• 使用进程模糊测试程序
• 需要编写一个利用程序，如下所示：

当你想模糊测试程序的某个部分时，这是非常有用的。

参考：

https://lcamtuf.blogspot.com/2014/10/fuzzing-binaries-without-execve.html

https://lcamtuf.blogspot.com/2015/06/new-in-afl-persistent-mode.html]

模糊测试策略

AFL采用了以下模糊测试策略

参考资料:

https://github.com/google/AFL/blob/master/docs/technical_details.txt

模糊测试中涉及的步骤：

语料库集合

• 一个好的文件语料库将有助于在短时间内发现路径。
• 使用回归/测试案例语料库，如果该软件/libs有的话。

例如：

• 图像文件语料库-> https://lcamtuf.coredump.cx/afl/demo/
• 多媒体文件语料库 -> http://samples.ffmpeg.org/
• 其它-> Search github/google

语料库最小化

为什么我们需要最小化输入语料库？

• 过滤掉没有形成新路径的文件。
• 过滤掉大文件

怎么做？

afl-cmin –i input –o mininput -- ./program @@

根本原因分析

我们通过进行模糊测试发现了一个崩溃，现在怎么办？

• 文件中的哪个字段？
• 该领域有什么价值？
• 程序中的哪个条件？ -> =>漏洞<=

崩溃分类

如果我们发现了1-2次崩溃，那么我们可以做人工分析，但如果我们发现了几百次或几千次的崩溃呢？

• 许多可能是重复的？
• 如何对它们进行分类？
• 这就是所谓的崩溃分类。

有各种可用的工具，例如：

Crashwalk, atriage, afl-collect